Nice! I love the new subcommand names! 🚀 🥳

I wouldn't worry too much about breaking changes for Pact Python. The workflow would be:

1. If you're using pact-python[compat-v2], it will install the old v1 CLIs to preserve backwards compatibility.
2. If you're using pact-python, the CLIs aren't installed anyway, and you can install pact-python-cli with either v1 for compatibility, or v2 to get the new ones.

Basically, there's no big risk in upgrading, because Python's version management will allow people to downgrade.

Quick question though:

Why add the PACT_CLI_LEGACY environment variable (and associated logic around that)?

If people want to use the legacy CLI, could we not just direct them to download the old CLIs?

The main benefit I can see with having the env-var toggle would be to support running both old and new CLIs... but is that really important?

the standalone package recently added all the rust tools to allow people to switch over.

they were introduced as new commands, so people needed to opt in to use them, without an easy way to switch between ( they dont have the same command names or args )

if we introduce a breaking change in this packaging, it means peoples workflows will automatically migrate over to use the new binaries.

with any luck, no-one is using the old ruby tools with exception to the pact broker client.

if they are, only pact-broker-cli has been designed with a one to one mapping of args, but there may be times when this isn’t the case, and definitely isn’t the case for the other ruby -> rust crates.

i actually think an easier way to roll out a change where we use legacy clis and it is opt in to use new ones via env var, avoid breaking peoples flows. any tooling can update over time, it will air out argument incompatibility and we can add shims in rust tooling ( verbose flag in ruby is available in rust pact broker cli, but hidden and will map to log-level info )

the same approach could be taken for a no action upgrade from ruby to rust binaries, with shims removed at a later date

once we sort packaging out for the pact consolidated rust cli ( homebrew / docker / script / action ), we could flip the env vars to be opt out in pact standalone.

alternatively, we remove all rust tools from bundle, create a new rust based distribution that similar to the suggestion of extensions for downloading/using pactflow-ai, it can download the legacy standalone if a legacy command is used.

i approached the extension angle like gh in the first take on the cli and had an approach to download the ruby standalone bundle ( it was actually to run a standalone broker, but the principle is the same )

cli exts https://github.com/YOU54F/pact-cli/blob/archive/main/src/cli/cli_extension.rs

downloading traveling ruby package on users machine

https://github.com/YOU54F/pact-cli/blob/archive/main/src/cli/pact_broker_standalone.rs

i have a not yet public repo for a rust based traveling-ruby package that embeds the entire standalone in the rust binary, and unarchives prior to execution.

embedding isnt preferable due to size, so we can download on the fly, following example from convo in pactflow ai pr

pact extensions install pact-legacy
pact broker-legacy publish
pact stub-legacy

Nice! I love the new subcommand names! 🚀 🥳

I wouldn't worry too much about breaking changes for Pact Python. The workflow would be:

1. If you're using pact-python[compat-v2], it will install the old v1 CLIs to preserve backwards compatibility.
2. If you're using pact-python, the CLIs aren't installed anyway, and you can install pact-python-cli with either v1 for compatibility, or v2 to get the new ones.

Basically, there's no big risk in upgrading, because Python's version management will allow people to downgrade.

thanks dude, appreciate the info, and how the workflow would look like

ahh okay so they get one or the other either automatically with v2 compat for main package or manually via cli package, could you install both cli packages together by doing install twice once with compat flag?

The main benefit I can see with having the env-var toggle would be to support running both old and new CLIs... but is that really important?

i do like this proposition, it makes switch between and testing a migration easier for me, and in something like the pactflow actions, i was planning on following same approach to allow the existing action to be used in compat mode.

basically the workflow there is use rust binary via its install script and bypass the existing docker cli altogether, unless the legacy env var is set.

maybe i am bleeding my testing/migration/maintainer brain into userspace.

i am just worried about breaking peoples existing workflows and trying to find the most seamless path to get people used to the new rust core.

if we just remove rust tools from here completely, that also works for me and reduces complexity/duplication

ps i have some ruby and rust side by side examples of the mock, verifier and stub in order to document the migration path for users :) they are in the pact-cli repo under examples https://github.com/YOU54F/pact-cli/tree/main/examples

Cheers for the inspiration.

KISS in action.

Much simplified approach in pact-foundation/pact-cli#8 which will remove a-lot of complexity and cognitive load, which was the aim of this whole exercise anyway!

I saw these messages and had it on my radar to review this week after the hackathon.

Not gonna lie, this new PR is definitely in the right direction!

ahh okay so they get one or the other either automatically with v2 compat for main package or manually via cli package, could you install both cli packages together by doing install twice once with compat flag?

Short answer: no. Python does not typically allow you to install multiple versions of the same package within the same environment. If you really had to, you would need to do some weird shenanigans, or have a separate venv.

Love the new PR 🚀